home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19960209-19960425 / 000097_news@columbia.edu _Mon Feb 26 10:53:18 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Return-Path: news@columbia.edu
  2. Received: from apakabar.cc.columbia.edu (apakabar.cc.columbia.edu [128.59.35.159]) by watsun.cc.columbia.edu (8.7.3/8.7.3) with ESMTP id KAA25982 for <kermit.misc@watsun>; Mon, 26 Feb 1996 10:53:18 -0500 (EST)
  3. Received: (from news@localhost) by apakabar.cc.columbia.edu (8.7.3/8.7.3) id KAA23956 for kermit.misc@watsun; Mon, 26 Feb 1996 10:53:15 -0500 (EST)
  4. Path: news.columbia.edu!sol.ctr.columbia.edu!news.msfc.nasa.gov!newsfeed.internetmci.com!newsxfer2.itd.umich.edu!agate!dog.ee.lbl.gov!news.cs.utah.edu!cc.usu.edu!jrd
  5. From: jrd@cc.usu.edu (Joe Doupnik)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: (no subject) Compression
  8. Message-ID: <1996Feb24.154611.74932@cc.usu.edu>
  9. Date: 24 Feb 96 15:46:11 MDT
  10. References: <4gf8o1$qdp@grimsel.zurich.ibm.com> <4gn4dc$9mt@krel.iea.com>
  11. Organization: Utah State University
  12. Lines: 54
  13.  
  14. In article <4gn4dc$9mt@krel.iea.com>, andersr@comtch.iea.com (Rod Anderson) writes:
  15. > Frank da Cruz (fdc@watsun.cc.columbia.edu) wrote:
  16. > 
  17. > <snip>
  18. > 
  19. > : Protocol", which contains the Kermit protocol specification.  Briefly: it
  20. > : is a character-oriented form of run-length encoding, and yes, the protocol
  21. > : negotiates whether it is to be used, and so it is a matter of the user
  22. > : interface providing a function to let the user enable it and disable it.
  23. > : However, there is rarely a reason to disable it -- it is quite efficient,
  24. > : very cheap in CPU cycles and memory, and in general has no downside at
  25. > : all.
  26. > 
  27. > And not to argue with `the' expert but to re-enforce his point: I can 
  28. > say it is VERY efficient!  Normally I down/up load binary (compressed) 
  29. > files.  The other day I down loaded a text file.  I have compression on 
  30. > my Sportster 14.4 disabled (for testing) and still went from a 1500+ 
  31. > char/sec. to a 2300+ char/sec.  So what this means to me is; when 
  32. > compression was needed it is used and when not it isn't.  No worries if you 
  33. > can't compress or uncompress you files at either end.  Kermit will get 
  34. > you the best possible transfer rate.
  35. >    I haven't tried to turn off Kermit compression and turn on modem 
  36. > (hardware) compression to see if I get better transfer rates.  With 
  37. > residential phone lines this seems good enough for me. 
  38. > 
  39. > Now back to hte real source.
  40. > 
  41. > : - Frank
  42. > 
  43. > Rod
  44. ----------
  45.     I think I gather the intent here, which is to squeeze the last
  46. bit per second by not attempting to compress already compressed material.
  47. Exactly the same situtation arises with modern tape drives which have
  48. compression done on silicon. The drives don't back away after discovering
  49. the stream has compressed material at this instant, though they could if
  50. the designers wanted to. Apparently modem designers feel the same way:
  51. it's more trouble than its worth to back away.
  52.     It needs to be said that modern LZ style compression is more efficient
  53. than run length encoding because the dictionary is larger than one character.
  54. We considered LZ class compression for Kermit and decided that a) it's a
  55. memory hog with even moderately decent 12 bit code words and b) the legal
  56. status of the algorithms is far from clear. Someone with an interest in
  57. the topic may want to generate a Master's Thesis on compressing to a
  58. restricted alphabet, only ASCII printables, rather than to long binary
  59. patterns.
  60.     That said I should also add the comment that we all know the transfer
  61. rate over the Internet is in continual decline. I tell folks it is inversely
  62. proportional to the number of people discovering the Internet (or to the value
  63. of money, whichever is declining faster). Pretty soon FedEx can make a fortune
  64. delivering packets rather than packages; they have more bandwidth with a box
  65. of tapes or CD-ROMs and the delay time isn't that much different at peak
  66. hours. Sigh.
  67.     Joe D.